Version: 12.10.0

Branching strategy

We follow a Trunk-based development approach to streamline our workflow and ensure continuous integration. The main guidelines are as follows:

Short-lived branches are used for specific tasks or features and are merged back into the trunk frequently.
All development work is done on a single develop branch, referred to as the 'trunk'.
No long-running branches are allowed.

Branching Rules

No root branches are allowed.
Branch names should follow camel-case notation
Each branch should have a dedicated subfolder according to its purpose, such as task, bugfix, feature, etc.
First name part is thr type of ticket/item, second part is the ticket number to which these changes belong. Last part is the description of what changes you are making in the PR. Make the branch names meaningful so that others also can understand what you are conveying

For instance:

Make sure to put the user story in the title of the Pull Request and include helpful details in the description of the PR. Include screenshots and any other details that will describe the work you did. This helps not only the code reviewer but only so future generations who are examining the history to understand what life on Earth was like
Make sure your code is latest with development/ release branch. It’s the developer’s responsibility to make it sync with the dev branch.
Please ensure SwiftLint validation is performed, and any issues or warnings are fixed and pushed. This will help avoid code smell issues.
Make sure to add test the logic that you are writing in the viewModel. It would make everyones life easier
Make sure the title of the PR should name like this

Team Name | Platform | Type of ticket | Ticket Number | Description

 Example PR name:  "Pool | iOS | Tech Debt | PLATT-17899 | Adding sonar qube exclusions"